Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Enable Hole Punching service #1766

Closed
wants to merge 3 commits into from

Conversation

diegomrsantos
Copy link

Description:

Enable the Hole Punching Service.

Copy link
Contributor

@alrevuelta alrevuelta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for this @diegomrsantos!

does a private node with this code get inbound connections out of the box as it is in the waku network?

@@ -186,7 +197,8 @@ proc new*(T: type WakuNode,
sendSignedPeerRecord = sendSignedPeerRecord,
agentString = agentString,
peerStoreCapacity = peerStoreCapacity,
services = @[Service(getAutonatService(rng))],
services = @[Service(hpservice)],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just to make sure i got it right: autonatservice is included indirectly in hpservice? so no need for services=[hpservice, autonatservice]?

wondering what would happen if i try:
services=[hpservice, autonatservice]

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, autonatservice is added at line 184. Regarding your second question, it'd create two autonatservice, I didn't test it tbh, but it shouldn't be done.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the hpservice as a wrapper around autonatservice, so I think we don't need to add it twice.

https://github.com/status-im/nim-libp2p/blob/74c402ed9db4652a455c00c8d1713b222e3ef3d5/libp2p/services/hpservice.nim#L110

@@ -54,6 +54,9 @@ proc setupNat*(natConf, clientId: string,
endpoint.udpPort = some(extUdpPort)

else: # NatNone
if natConf == "none":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isnt this redundant? its the else case of if strategy != NatNone: so it will always be none?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but before it executed the code below:

    if not natConf.startsWith("extip:"):
      return err("not a valid NAT mechanism: " & $natConf)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we just return an error in this case (else: # NatNone)?

I have the impression that the next is always run:

return err("not a valid NAT mechanism: " & $natConf)

@@ -42,6 +46,8 @@ import
./peer_manager,
./waku_switch

export chronos
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this needed?

Copy link
Author

@diegomrsantos diegomrsantos May 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Menduist do you have more info about this issue? Is there a PR related to that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't remember, what happens without this line?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't remember the error now, but it is related to generic procs. I think adding the export is the only way to fix it. I believe in this case it is caused by the new proc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, if you use a package inside a generic proc, you need to export it
Not a bug, just a design quirk of nim

let relayClient = RelayClient.new()
let autoRelayService = AutoRelayService.new(1, relayClient, nil, rng)
let autonatService = getAutonatService(rng)
let hpservice = HPService.new(autonatService, autoRelayService)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wondering if we should have hole punching behind a flag or always on by default. specially now at the begining that its new. opinion? @jm-clius

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a flag that is true by default

@Ivansete-status
Copy link
Collaborator

Ivansete-status commented Jun 2, 2023

Thanks so much indeed for submitting this PR @diegomrsantos !
May kindly elaborate a bit more on its description please? For example, the next sections might help:

  • summary.
  • deeper details about what this PR addresses.
  • issue. If exists, a link to the issue that needs to be sorted out.

You'll need to set an appropriate PR's title.

And, in order to fix the conflicts I would make this in your working branch:

  •  git fetch origin
    
  •  git rebase origin/master
    
  • fix the possible conflicts :)

@diegomrsantos diegomrsantos marked this pull request as draft June 2, 2023 12:29
@diegomrsantos
Copy link
Author

@Ivansete-status Sure, I'll do it. Sorry, should have created it as a draft.

@Ivansete-status Ivansete-status changed the title Enable Hole Punching service feat: Enable Hole Punching service Sep 13, 2023
Copy link
Collaborator

@Ivansete-status Ivansete-status left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks great indeed!
I've added a little nitpicky comment.

How could we test it?

.withAutonat()

if relay != nil:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Little nitpick:

Suggested change
if relay != nil:
if not isNil(relay):

@@ -186,7 +197,8 @@ proc new*(T: type WakuNode,
sendSignedPeerRecord = sendSignedPeerRecord,
agentString = agentString,
peerStoreCapacity = peerStoreCapacity,
services = @[Service(getAutonatService(rng))],
services = @[Service(hpservice)],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the hpservice as a wrapper around autonatservice, so I think we don't need to add it twice.

https://github.com/status-im/nim-libp2p/blob/74c402ed9db4652a455c00c8d1713b222e3ef3d5/libp2p/services/hpservice.nim#L110

@diegomrsantos
Copy link
Author

diegomrsantos commented Sep 19, 2023

@Ivansete-status @jm-clius I'm putting this work on hold for now. The Hole Punching Service requires that a private peer's relay address be advertised to peers interested in connecting to it. We are going to use the Rendezvous protocol for that, but the current nwaku version is just mounting the protocol. Advertising the peer's signed record, requesting other peers ones, and using it to discover new peers need to be implemented. It seems those things are already in place in go-waku. Please let me know when those have been implemented in nwaku and fully tested with go.

@Ivansete-status
Copy link
Collaborator

@Ivansete-status @jm-clius I'm putting this work on hold...

Thanks for the comment @diegomrsantos! Is there anything that we should do to help this feature progress?
Kind regards

@diegomrsantos
Copy link
Author

@Ivansete-status If I get it right, circuit-relay addresses from private nodes aren't discoverable through discv5, because they are too big. For that reason, nwaku nodes need to use Rendezvous to advertise such addresses when they are private. Likewise, they also need to ask Rendezvous Points for such node's addresses.

@Ivansete-status
Copy link
Collaborator

Thanks for the answer @diegomrsantos!
Then, in order to make this Hole Punching service PR progress we first need to achieve the next items right?

  • nwaku should use Rendezvous to advertise "circuit-relay addresses" when they are private.
  • nwaku should ask Rendezvous Points for "circuit-relay addresses".

@diegomrsantos
Copy link
Author

That's correct. Regarding the first point, nwaku could use Rendezvous to advertise its addresses all the time, not only when it's private. This would probably make the implementation easier, but I'm not sure about the interaction with the current discv5 usage. This can be decided by the team, the only requirement for Hole Punching is that circuit-relay addresses of private nodes are advertised, discoverable, and dialed by other nodes.

@diegomrsantos
Copy link
Author

diegomrsantos commented Sep 22, 2023

I have added the advertising part (in all cases, not only when the node is private) here f64d12b. It can be used as inspiration, I'm not sure I did it properly.

It requires some fixes that are being done here vacp2p/nim-libp2p#951.

@Ivansete-status
Copy link
Collaborator

Thank you so much indeed for this PR @diegomrsantos!
It has been very inspirational but discontinued because it diverged quite a lot from the current master branch.
Therefore, we are tackling it in the following PR: #3112

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants